Components within a computer system are typically connected to each other using a bus. A first component communicates data to a second component by writing data to the bus. A second component then receives the data by reading the bus. More than two components may be connected to a bus so conventions exist that allow a given component to determine whether the data on the bus is destined for that component or for a different component. However, the architecture of many such busses is such that any component can connect to the bus, and can request and receive data off the bus—even if the data is not intended for that component. Thus, the bus provides an opportunity for spoofing devices and/or snooping or modifying data, so typical busses may not be appropriate for transmitting private data in the clear.
One context in which it may be undesirable to place data on a typical bus is where the data could identify the user based on a unique hardware identifier. For reasons of privacy, many users are wary of unique hardware identifiers, and resist using hardware that employs such identifiers. However, some hardware components employ unique public/private key pairs in order to engage in encrypted communication. While identifying the user is not the primary purpose of the key pair, the public key is, in fact, substantially unique to the hardware and could be used for such an identifying purpose. Since the public key must be transmitted to the entity that will use the key to encrypt information, the typical transmission of the key over a bus provides an opportunity for this potentially identifying information to be divulged. Thus, there is a probability that unauthorized (by the machine's owner/user) software could initiate requests for such unique IDs, then use the IDs in malicious ways to correlate/profile user activity on the internet, etc.
In view of the foregoing, there is a need for a system that overcomes the drawbacks of the prior art.